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(57) ABSTRACT 

The invention concerns a method for providing a service for 
users of a telecommunication network. Service calls request- 
ing the execution of the service for an respective one of the 
users are routed to a service switching exchange of the 
telecommunication network or are respectively routed to one 
of several service switching exchanges of the telecommu- 
nication network. A corespondent service request is sent by 
the respective service switching exchange, that has received 
the respective service call, to a service control facility or to 
one of several possible service control facilities. For each 
such service request received from the or each service 
switching exchange a service session object, which is able to 
interact and communicate via an object infrastructure with 
other objects in a object oriented computing environment, is 
created within the or each service control facility and the 
respective service session object controls the execution of 
the service for the respective service call. 

18 Claims, 4 Drawing Sheets 
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METHOD OF PROVIDING A SERVICE TO network, in which method service calls requesting the 

USERS OF A TELECOMMUNICATION execution of the service for an respective one of the users are 

NETWORK, SERVICE CONTROL FACILITY, routed to a service switching exchange of the telecommu- 

AND PROCESSING NODE nication network or are respectively routed to one of several 

5 service switching exchanges of the telecommunication net- 

CROSS-REFERENCE TO RELATED work and in which method a corresponding service request 

APPLICATIONS is sent by the respective service switching exchange, that has 

t, . v , _ _ , • , ... • rt , p . received the respective service call, to a service control 

This application discloses subject matter that is disclosed - .... t r e , ' . 4 ir 

. V l i- j • J j. 4 . facility or to one of several possible service control facilities, 

and which may be claimed m copending patent applications ch J acterized in that for e P ach such XIvic , request received 

entitled Method for Communicating Between a Service 30 iL , . t , n 

c r-p | • kt * i a fr° m lne or eacn service switching exchange a service 

Switching Exchange of a Telecommunication Network and ,. . i_- i_ • i_i . • . - i • * 

0 • ^ . i ? *v* fii -j a n ,nno/nc n* kt session object, which is able to interact and communicate via 
a Service Control Facility, filed Apr, 9, 1998 (U.S. Pat. No. ,. . J . r ' ... ,. . . . 

Acxa j a c t\ j * * i * an object infrastructure with other objects in a object on- 

6,266,406 Bl); and "Method of Providing at least One t . J 4 . /, . +u . 4 , J , 

o • * it * • xt * i c * ented computing environment, is created within the or each 

Service to Users of a Telecommunication Network, Service . V , % .... ,7 

. „ xt j » j . ^ _ service control facility and the respective service session 

Control Facility and Server Node , filed on even date 35 . ' • * 

u .1. /tto n « xt /r ni \ l tL c u • i_ object controls the execution of the service for the respective 

herewith (U.S. Pat, No. 6,201,862 Bl); both of which are • « 

. . • . i . r service call. 

hereby incorporated by reference. , r , . , , 

According to a second aspect of the invention, a method 

BACKGROUND OF THE INVENTION for provisioning the execution of a service logic function 

1 Technical Field 20 w i tmn a service control facility of a telecommunication 
J, . , . . . .. systems, where service requests, that request the execution 
The invention concerns a method for providing a service / f M i Al nn a u,, „^„,- m 

- , . r , & , t _ or the service logic function, are received by the service 

for users of a telecommunication network, a method for . 1f T . / , • •« . * . 

.... . r . . ' . ... control facility from at least one service switching exchange 

provisioning the execution or a service logic tunction within c# , , . ... , . , . ?. . ? 

r . & . & . of the telecommunication system, is characterized in that for 

a service control facility or a telecommunication system, a , . / ■ , c *l * i * 

. 3 , ->c each such service request received from the at least one 

service control facility for connecting to one or several ^ . , . 7 . t . 

... f ? , . service switching exchange a service session object, which 

service switching exchanges or a telecommunication net- U1 t . , f , . , . . . r 

6 . 6 , _ ,<•-,. is able to interact and communicate via an object mfrastruc- 

work and a processing node for a service control facility 4 -a. *u u- * • u- * • ♦ j 

« * & ... . J „ ture with other objects in a object oriented computing 

connected to one or several service switching exchanges of environment) fe cre J ated within th J e f ^ 

a telecommunication network. ^ and ±Q respective service session object handles ^ execu . 
2. Discussion of Related Art tion of me ^^icc logic function for the respective service 
Telecommunication services can be provided according to request, 
the Intelligent Network Architecture. According to a third aspect of the invention, a service 
A user of a telecommunication network requests a service control facility for connecting to one or several service 
by dialing the number dedicated to the service. The call with 35 switching exchanges of a telecommunication network, 
this number is routed through the telecommunication net- where the service control facility contains means for receiv- 
work to a service switching exchange which recognizes this ing service requests, that request the execution of a service 
call as a call requesting the service. Then, this service for a user of the telecommunication network, from at least 
switching exchange communicates via a data network with one of the service switching exchanges of the telecommu- 
a service control facility, the so called service control point. 40 nication network, is characterized by containing means for 
This service control point contains a service logic which creating for each such service request received from the at 
contains a description of the method that has to be executed least one service switching exchange a service session object 
to provide the service to the calling user. By a request of the within the service control facility, means for enabling each 
service switching exchange the execution of this method by service session object to interact and communicate via an 
the service logic is initiated and the requested service is 45 object infrastructure with other objects in an object oriented 
provided to the requesting user. computing environment, and means for executing under 
This service logic is realized as a single process handling control of the respective service session object a service 
all calls one after the other. Each of them going through a logic function for the respective service request, 
single queue. Each call is associated with a context allowing According to a fourth aspect of the invention, a processing 
the state of the call not to be lost between user interaction. 50 node for a service control facility connected to one or several 
The service is executed through a finite state machine, taking service switching exchanges of a telecommunication 
as input the TCAP message and the context of the call. network, where the processing node contains means for 
The disadvantage of this approach is that this architecture receiving service requests, that request the execution of a 
of provisioning services is that within the service control service for a user of the telecommunication network, from at 
facility an incoming request for a service has to wait for 55 least one of the service switching exchanges of the telecom- 
execution until the current one has been processed out. munication network, is characterized by containing means 
Therefore, the rate of service requests that can be handled by for creating for each such service request received from the 
the service control facility is strictly limited. at least one service switching exchange a service session 

object, means for enabling each service session object to 
60 interact and communicate via an object infrastructure with 

Accordingly, it is a primary objective of the present other objects in an object oriented computing environment, 

invention to increase the number of service requests that can and means for executing under control of the respective 

be handled by a processing node that is involved in the service session object a service logic function for the respec- 

cxecution of services for users of a telecommunication tivc service request. 

network. 65 Th e underlying idea of this invention is that for each 

According to a first aspect of the invention, a method for service request received from a service switching exchange 

providing a service for users of a telecommunication a service session object, which is able to interact and 
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communicate via an object infrastructure with other objects such a service request, it sends a corresponding request via 

in an object oriented computing environment, is created the network KN2 to one of the two service control facilities 

within the control facility and the respective service session SCP1, SCP2. The service is then provided under the control 

object controls the execution of the service for the respective of the respective one of the service control facilities SCP1 

service call. Therefore, the service architecture is no longer 5 anc * SCP2. 

based on a functional design and technologies like multi- Each of the service control facilities SCP1 and SCP2 

threading or multi processing can be applied. provides one or several services S and realize a service 

Due to the introduction of an object oriented computing C °?l r0 ^ ^ unct ^ on ; t 
environment and the special object design described above, ™ e communication network KN2 is preferably a data 
the processing of the service requests can be distributed and 10 network, especiaUy according to the SS7 signaling protocol. 
*w j i • 1 , ~? *i-p i 4 r . , j It is also possible that this network is a LAN (Local Area 
this proved high scalability and IT platform independency N&M) % MAN (Metropolitan Area Network or an ATM 
The redesign of the service logic according to this approach (Asyach ; m Trimsfer Mode) network . 
allows for easy seme* interworking personal, zal.on d.stn- PreferablV) the service switchin excn ss P1> SSP2> 
bution and maintainability ■ of the software The design and the communication between them and the service con- 
pattern allows for taking aU benefits from object oriented M lrQ , fadlilies scpl( scp2 afe designe(J according t0 lhe 
programming. Intelligent Network Architecture (according to the service 

Furthermore, it allows introduction of multithreading. switching point and according to the communication 

The direct benefit is that a service session, that means the between the service switching point and the service control 

processing of a service request, is not blocked by the point), described for example in the ITU-T Q.1214 Recom- 

execution of another one. 20 mendation. 

The use of a factory allows implementation of several life If a user wants to start an service S, he dials a specific 

cycle policies for the service session objects. number for that service. The local exchange will route this 

It is further advantageous ca ^ t0 me nearest service switching exchanges and this will 

t • , . , • , Ji-.j ^^nriA trigger the service switching functionality SSP to start the 

to implement each service by a dedicated CORB A server. 25 . . , , ?. t * it _ „™ t 4 

c r u „ . . , n , , , service. This is done by sending a request to the SCP to start 

Each call to the service is handled then by a single „ . \ .J? ™ * ™ ™ ■ 

CORBA ob'ect* executing a Service Logic Program (SLP). An SLP is 

J ' specific for each service, it will instruct the network on how 

to manage the creation of a service session object by a t0 handk me It ^ execute service logiCj statistic 

service dedicated factory; logiC) database logiCj cha rging logic, etc. It will also provide 
to set the interface definition of a service session object as instructions for the switch (e.g., create the second leg of the 
TCAP mapped over IDL. call) and Intelligent Peripherals (IP) (e.g., announcement 
By the use of CORBA (Common Object Request Broker machines). A protocol according to the Information Net- 
Architecture) servers the service control facility implemen- working Architecture (INAP) is used for this, and INAP 
tation is simplified and scalability is ensured. messages are transported in TCAP (Transactional Capabili- 
ties Application Part) messages between the SCP and SSP. 
When designing a distributed application, first the pos- 
FIG. 1 is a block diagram presenting the architecture of a sible system components to be distributed are identified (i.e., 
telecommunication system containing a service control what the objects of the system are and how they will be 
facility according to the invention. 40 grouped into larger objects that will be distributed). 

FIG. 2 is a block diagram presenting a first object archi- ^ breaking down of the SCP into objects offers some 

lecture of the telecommunication system. possibilities. FIGS. 2 to 3 depict these organized into dif- 

FIG. 3 is a block diagram presenting a second object fe ™ 1 architectures. All state information for handling one 

architecture of the telecommunication system. cail was ke P l l 0 * ethcr and * at a11 f^ n da * was °*&™™<* 

_^ A . , , , ,. . as into objects. So, one possibility for SCP objects is a script 

FIG. 4 is a block diagram presenting a third object object that executes the j ic for Qne caU afld an 

architecture of the telecommunication system. object per data object 

FIG. 5 is a block diagram presenting a object architecture ^ values of tne data ob j ects m kept in a databasCj ^ 

of a service switching exchange for the telecommunication having data ob j ects that hide the use of a database is 

system. 5Q preferable (i.e., certain independence on the database). The 

DETAILED DESCRIPTION OF PREFERRED catch lies in the fact that making these objects CORBA 

EMBODIMENTS objects gives us a considerable overhead when methods 

(e.g., to read or write attribute values) are called on them. So, 

FIG. 1 shows a telecommunication system TS with an the system performance would become unacceptable, 

telecommunication network KN1, a subscriber terminal T 55 script ob j ect could be decomposed into a service 

assigned to a subscriber A, a communication network KN2 execution engine and an SIB graph. So, SIBs could become 

and two service control facilities SCP1 and SCP2. distributed objects too. If database objects are distributed, 

The telecommunication network KN1 is for example a this offers the possibility to execute an SIB on the machine 

telephone network. It is also possible that this network is a where the particular data object resides. We can envisage a 

data network or a communication network for mixed data 60 scheme where there is a control entity (a script) that executes 

speech and video transmission. SIBs remotely (possibility of having more overhead) or a 

From the exchanges of the network KN1 two special scheme where control is passed from SIB to SIB. This trade 

designed exchanges SSP1 and SSP2 are shown. These off between getting the data and running a script on one 

exchanges are service switching exchanges that contain a machine and running parts of a script (SIBs) where the data 

service switching functionality SSP. To these exchanges 65 resides is certainly worth investigation, 

service request calls from the subscriber of the network are The SSPs main functionality is to provide a hook between 

routed. When such a service switching exchange receives the call processing and the IN system. An SSP server must 



BRIEF DESCRIPTION OF THE DRAWING 



09/17/2003, EAST version: 1.04.0000 



US 6,3 

5 

at least have an object that bridges between the normal Call 
Control Function (CCF) and an object that bridges between 
the Switching Function (SF). Also an object that bridges 
between Specialized Resources (SRF) (e.g., announcement 
equipment), seems to be obvious. In FIG. 5, these objects arc 
depicted as a Switching Control, Call Control and Special 
Resources Object. We also need an object, Call Handler 
(CH) that interlaces with the SCP and the other objects in the 
SSP. There are two possibilities: there will be only one that 
handles all calls, or several, each handling one call. If we 
have several, existing only for the duration of the call, we 
also need a corresponding factory object to control the 
lifecycle of these objects. 

In the following is given the architecture of an SSP server 
on CORBA. 

For the Switching Control, Call Control and Special 
Resources objects we could have two approaches. In the first 
approach they are only interface objects between the pro- 
prietary Application Program Interface (API) of existing 
software. In the second approach they would control the 
hardware directly, what implies providing a CORBA inter- 
face to Switching Control, Call Control & Special 
Resources. In theory this would be the best solution, since 
the approach would give an overall consistent software 
architecture, in this case special IDL (Interface Definition 
Language) adapter interfaces have to be designed. 

An SMP (Simple Management Protocol) is responsible 
for service control and monitoring. In order lo be able to 
control services, the SMP does not need to be a DPE object. 
What is needed is that the objects that are controlled (e.g., 
script) provide an interface to do so. For monitoring we need 
an SMP object that is able to receive "events" from the 
objects that are being monitored. In our research prototype 
we defined and implemented a trace control as an example 
on what is possible as management functionality on the SCP. 

In the previous section we have described a number of 
possibilities for CORBA objects in an IN Architecture. In 
this section we will group certain of these CORBA objects 
into a specific architecture. The sequence of the architectures 
can be seen as a possible evolution scenario, starting from 
current day's service provisioning, especially IN, products. 

The basis of the first architecture is the usage of a 
distributed database for data distribution and CORBA dis- 
tribution for distributed SCP. This architecture is designed to 
interface with existing SSPs, so the SSP is not a CORBA 
object. Since this architecture was used to implement a 
research prototype, we elaborate on it more than the others. 
FIG. 2 depicts the architecture. 

The basic components in the architecture are: 

the script: a CORBA object that handles exactly one call 

the SLI (Service Logic Interface), a CORBA object that 
handles a TCAP dialogue for, and interfaces with the 
SSP. 

the distributed DB. 

Existing IN service scripts can encapsulated in Script 
objects. 

A Script object also contains the Service Data and Call 
Context related to a particular call, and one Script object is 
instantiated per call. The interface of the Script object 
contains operations that represent the TCAP messages that 
the Script receives during its execution. 

A special Service Logic Interface (SLI) object receives 
the #7 messages from the SSP and dispatches them to the 
corresponding script object instantiation, using the ORB 
services. The interface of the SLI object contains the TCAP 
messages that can be sent to it. One SLI object is instantiated 
per call. 
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Since the Script and SLI objects exist only during the 
lifetime of a call corresponding factory objects are used to 
create and destroy them. Data objects are not CORBA 
objects, they are implemented as C++ objects. This approach 

5 hides the use of a particular database from the service logic. 
It is possible to use as database for example Oracle, 
SQLNET or ObjectStore. The SMP has not be considered; 
we could have used the proprietary mechanism to send 
status information to it, or defined it as a CORBA object with 
an appropriate IDL interface. 

However as an example on what is possible, its easy 
possible to design and implement a small trace control 
system; each server has a tracer object, the trace control part 
of the SMP can call methods to turn traces on particular 
implementation objects on and off. The SMP also manages 

15 the database (using SQLNET). 

A script and a SLI are CORBA objects, how they are 
distributed over servers is a deployment issue. A CORBA 
server is a process running at a particular node in the system. 
There is one SLIServer in the system that interfaces with the 

20 SSP. It has one CORBA object, the SLIFactory, that is 
always present when the server is running. 

The main purpose of this object is to create new SLI 
objects when new calls are started (when a TCAP dialogue 
is opened). The SLIServer is deployed in the node that has 

25 the #7 hardware and software installed. The system can have 
a number of ScriptServers, one per available node. 

This server also has a factory object, that exists during the 
lifetime of the server itself. This factory object is registered 
in the CORBA Naming service, so that an SLI can find it. In 

3o this way service logic distribution is facilitated. Adding 
more processing power to the system just means installing 
the new machine, running the ScriptServer on it, and the 
next time the SLI looks for a ScriptFactory a new possibility 
is available. The same mechanism also provides some 
reliability, when a machine goes down for some reason, the 

35 SLI will simply not get a reference to that ScriptServer any 
more. Note that the ScriptFactory is also to best candidate to 
put a management interface on (e.g., to change the service 
characteristics), since it is always available as long as the 
server is running. 

40 The interface between SLI and Script is defined to be 
asynchronous and in terms of TCAP primitives (BEGIN, 
INVOKE, RESULT, . . . ). This option is advantageous, since 
one of the requirements is to reuse existing IN product 
software. Another option is to define this interface in terms 

45 of INAP primitives. 

The difference between a CORBA object, a (CORBA) 
server and a process must be clear. A CORBA object 
implements an interface and runs within a CORBA server. 
The CORBA server itself is one process that runs on a host 

50 (or node). This definition is important for the relation 
between a script and a call. In the current ALCATEL IN 
product implementation a script is a process that handles 
different calls, and keeps a different call context for each of 
those. This is done for performance reasons, starting up a 

55 separate process (script) for each call takes some time. 

We could adapt a similar approach (one script handles n 
calls) in these architectures, but the fact that a script has 
multiple contexts is not that clean and it is possible to deal 
with the performance issue by having a CORBA server with 

60 multiple scripts (each handling one call). So, it is better that 
in this architecture, a host can run one or more CORBA 
servers, each running different script objects that each 
handle a specific call. 
The CORBA server is similar to the script in the current 

65 IN product, but the problem of handung multiple contexts is 
shifted from the application programmer to the CORBA 
platform. 
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A step further in this sequence of architectures, as second 
architecture, is to break down the script object into its 
components. As known, IN services are designed as a 
number SIBs that arc nodes in a service logic graph. The 
execution of the script means executing SIBs and moving to 
the next SIB depending on data and responses coming from 
the SSP. In stead of designing this as a monolithic piece of 
software (from the SCE), it could be designed in terms 
cooperating SIBS. As known, the IN capability set 1. SIBs 
are not sufficiently defined to used them as they are. This 
resulted in IN platform providers having their own set of 
SIBs derived from the standard and software from SIBs is 
not reusable among platforms. 

When SIBs are defined as CORBA objects this situation 
could be broken and service providers would be able to 
design their own services, reusing existing SIBs (source 
code). 

Having SIBs as independent CORBA objects offers the 
possibility to execute the SIBs in different places. Instead of 
getting the data (using a distributed database, or using 
CORBA objects) to the place where the script or SIB is 
executed, we could start lie SIB on the machine where the 
data is located. This brings benefits. We can envisage a 
scheme where there is a control entity (a script) that executes 
SIBs remotely or a scheme where control is passed from SIB 
to SIB. 

A third architecture breaks with traditional IN product in 
the sense that it also makes the SSP a CORBA object. In the 
previous architectures, for reliability reasons, it is still 
necessary that CORBA servers are deployed on machines 
that are interconnected on a reliable LAN. In practice, with 
the current DPE implementations (TCP/IP) this means put- 
ting the machines in the same location. This technology 
restriction prevents putting the SSP on the DPE, since in 
practice SCP and SSP sites are located on different places. 
However, technology evolves and DPE providers (e.g., 
IONA) are looking into the possibility of porting their 
product to other transport protocols, e.g., #7 links for 
telecommunication purposes. When this happens the step to 
making the SSP a CORBA object is not that big. In this case, 
the SLI object would not be needed anymore, since the SSP 
object could take over its role. When a call is started it gets 
a reference to a ScriptFactory and asks to create the script 
object itself. It could then communicate with this object 
directly. Also the language used in this communication 
(INAP encapsulated in a TCAP based interface) can be 
simplified. This interface could be defined in terms of INAP 
primitives (e.g., provide_instruction(args), join(args)). This 
would improve (simplify) the system design and 
implementation, since the TCAP layer disappears for the 
application programmer. One could say that when CORBA 
is used, the application programmer must only be concerned 
with the application layer of the communication, not with 
the session layer (when TCAP is used). 

The final step would be to extend integrate a terminal (as 
proposed by TINA (Telecommunications Information Net- 
working Architecture)). This would mean a major change in 
user equipment. However this change is not infcasible if we 
consider the fact that more and more users get connected to 
the internet over their telephone lines. And the technology 
needed to have the DPE extended to the terminal is similar 
to this. The benefit of this would be that the terminal to 
network protocol could become much richer than just pass- 
ing DTMF tones as numbers. 

The above described architecture provides a solution to 
make especially IN platforms more scalable. Since inter- 
working with and evolution from existing products is impor- 
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tant we presented a sequence of architectures that can be 
seen a possible evolution scenario. 

As example an implementation procedure according to 
the architecture 3 is described in the following: 

A Credit Card Calling service which existed for the UNIX 
based IN Release existing Alcatel product is to be imple- 
mented. The Credit Card Call service is a "typical" IN 
service and allows a call from any terminal to be billed to a 
particular card number. To set up that call, the user has to 
( enter a card number, a PIN code and the destination number. 
If the entered data is correct, the call is completed to the 
destination address and charged to the user's card. 

An SSP simulation stub was used to generate the TCAP 
dialogue for the Credit Card Call. The SSP stub is a CORBA 
object that sends and receives the same TCAP messages that 
15 an SSP would. The SSP stub is capable of simulating 
different call scenarios, can generate different call loads and 
can repeat a scenario an arbitrary number of times. 

Another general issue for the use of CORBA in an IN 
oriented service provisioning architecture is the interwork- 
20 ing of CORBA-based IN with legacy IN applications. 

This interworking can be achieved with the use of Adap- 
tation. It is related to the way a CORBA based infrastructure 
can communicate with the legacy of switching systems, 
namely SSPs. 
25 There are two approaches possible: 

1) Definition of an Adaptation Unit which is an application 
level bridge that provide the mapping of SS7 and TCAP 
primitives into IDL invocations. This approach is similar to 
one taken by the XoJIDM group for the CORBA/CMIP 

30 gateway. The result of their works can be reused especially 
the static mapping of GDMO/ASN.l to IDL interfaces. 

In order to minimize the impact on existing systems, 
CORBA should provide framework services and tools in 
order to achieve this mapping. The availability of such 

35 framework will allow interworking of CORBA-based IN 
with a variety of existing hardware such as SCPs and HLRs. 

Such application level bridge should be characterized by 
high availability and high performance without being a 
bottleneck for a distributed system. However for the 

40 required real-time performance, this is an intermediate solu- 
tion towards full IN CORBA-based systems. 

This approach would involve building an IDL interface to 
represent application level protocols such as MAP and INAP 
and others which are based on the TCAP layer. The TCAP 

45 layer provides a "ROSE-like" asynchronous RPC service 
over the SCCP layer. And basing the bridge on TCAP will 
exclude the use of circuit related signaling protocols such as 
ISUP and TUP from the solution. 

Like in the XoJIDM approach, there should be a static 

50 translation of the INAP/TCAP specification to IDL inter- 
faces which will be done by a dedicated compiler. Thus, any 
INAP dialect can be converted to appropriate IDL interfaces. 
These applications level bridges would implement these IDL 
generated interfaces and dynamically perform conversion 

55 between IDL-derived types and their ASN.l equivalents. 
CORBA nodes using the protocol specific bridges would 
generally run two servers, one each for processing outgoing 
and incoming invocations. Since TCAP is a connectionless 
service the gateway will have to maintain state in order to 

60 match invocations to responses and exceptions. 

2) Usage of SS7 as an Environment Specific Inter-ORB 
protocol (ESIOP): 

A possible solution is to map the CORBA GIOP on top of 
SS7 or to build a new Extended protocol (ESIOP) on top of 
65 the SS7 layers. 

The ESIOP solution would essentially use an SS7 proto- 
col as a transport for the GIOP protocol. CORBA objects 
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would be visible across the SS7 network in exactly the same reliability which denotes requirements that define accept - 

manner as they would be across the Internet with the able behaviors for the distributed applications in the 

CORBA HOP. This would allow as ORB to use existing SS7 presence of hardware and software failures. In this case 

infrastructure as transport. two types of reliability can be identified; the integrity 

It should be noticed that existing signaling networks were 5 state and the availability; 

never dimensioned to support the sort of traffic which will be manageability which denotes requirements that enable 

exchanged by CORBA nodes. However, there is a potential ease of development, deployment and operation for 

benefit in this approach by exploiting the fault tolerant complex applications (in this case maintainability, (re) 

nature of the SS7 network. configurability and extensibility of CORBA applica- 

The first issue here is the choice of SS7 protocol access 10 tions. 
level for this solution. The two principal choices are TCAP An asynchronous Invocation model commonly used by 
and SCCP: GIOP at TCAP level: IN applications is required. Thus, asynchronous and option- 
It should be possible to use TCAP for carrying GIOP ally isochronous invocation model is required with the ORB. 
messages since IT is essentially a ROSE-like service. Ser- The requirement here is a client side programming model 
vices which make use of TCAP must define their operations 15 which potentially supports a lightweight asynchronous com- 
using ASN.l modules. It is envisaged that ASN.l macros munication mechanism incorporating a mandatory callback 
would be used to define the operation set: Request, Reply, (or ORB "upcall" type mechanism) and optionally a 
CancelRequest, LocateRequest, LocateReply, Close Connec- "Futures" type programming model, 
tion and MessageError. These operations correspond to the For the same object, both asynchronous and synchronous 
GIOP primitives. The gateway would be responsible for 20 models should co-exist. The maximum concurrency level is 
converting CDR format, of the form used by GIOP, into a defined in the configuration (e.g., QoS parameters), and has 
form transportable using ASN.l types (possibly as an to be controllable, with the possibility of queuing the request 
opaque buffer with BER encoding). or returning an exception. 

While it should be possible in principle to use TCAP as A basic fault detection support should be provided by the 

the basis for the ESI OP, it is not suitable because of: 25 ORB runtime for any object which needs it. This can be done 

the complexity of the implementation. by a timer which is implicit set and managed in the client 

the overhead incurred in by the TCAP layer in process. 

addition to basic transport Flexibility and Scalability: 

the asynchronous nature of the protocol. ^ 0RB should be able t0 su PP ort applications handling 

ESIOP at SCCP Level* 30 a * ar & e num ^ er °f objects and should be able to support 

The other choice for implementing the SS7 ESIOP is at man y simultaneous connections to remote objects, 

the SCCP level. The SCCP provides services corresponding ^ memorv cost of an «™sed remote interface reference 

to the OSI-RM network layer functionality. It can operate in m a ^ ven ca P sule ( Le ** Umx P rocess ) should be <> f the order 

both connection-oriented and connectionless mode. It of a standard language pointer. 

should be feasible to use the SCCP to transport GIOP 35 A l yP lcal telecommunications environment comprises 

messages although the ESIOP code may be required to objectsof very different granulanties m both space (memory 

perform its own transport layer functions (e.g., end-to-end size ) and time ( ob J ect lifetime and duration). A scalable 

flow-control and segmentation/re -assembly). It should be ORB should support objects at different levels of granularity, 

possible to address CORBA nodes using the "Global Title" and mimmize the overhead associated with the handling of 

mode of SCCP addressing. It would appear that using SCCP 40 sma11 and volallle and of connections to remote 

as the basis for an ESIOP for the SS7 network would be the objects. 

best approach. To acfJ i eve some °f tne ORB fault-tolerance and 

The following requirements are advantageous for a object reliability, the CORBA object model could be enhanced to 

oriented environment for an infrastructure in which a service su PP ort 8 rou P s of ob J ects or globally known as group 

session object interacts (described by hand of the CORBA 45 communication such as those described. 

environment): Reliability and Availability: 

. . , f , . . t „ rtnT1A . ,, To achieve the reliability requirements, the notion of 

in terms of functional requirements, CORBA should „ ,. t A t , , . . / ^ . 4 « . . ™™ A 

. , replicated distributed objects can be introduced in CORBA. 

P ' Thus the critical components of the application are imple- 

asynchronous Invocation model and support for group 50 me nted through replicated objects. This replica management 

communication in the ORB; can be handled automatically by the ORB such that clients 

proper hooks for extending the ORB with security, trans- interacting with a given server object is not aware if it is 

action and replication mechanisms; replicated or not. The degree of replication can be deter- 

node management and minimal object lifecycle facilities; mined by the desired level of reliability which can be 

a time service and native monitoring facilities for captur- 55 measured wita lhe number of maximum number of concur- 

ing both computational and engineering events; ' ent failures; the nature of me failure which can be lv P ed 

support for multithreading with flexible event-to- thread ( raalicious ° r benign); and the type of reliability property 

mappings 8 sought such as integrity or availability. High avail- 
Hie non-functional requirements of CORBA are con- An 

cerned with* CORBA for distributed IN systems in order to ensure the 

. _ f ^ , , same robustness as current IN systems, 

^entifying the .level of scalability and object granularity Timeliness requirements can be also achieved by the 

that the ORB should meet in the IN context; replica service> Fof example> applications that need tc / have 

identifying the performance level that the ORB must bounded and predictable delays will be implemented 

achieve in terms of latency, throughput, etc.; 65 through replicated objects. Each replica is able to process 

providing a predictable ORB core by instrumenting and locally all of the methods defined for the object. In the 

documenting the time behavior of the platform; absence of failure, a client can use any of the responses to 
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a method Invocation as its result, (the invocations in this 7. A method as claimed in claim 5, characterized in that 

case is perform synchronously). the factory object implements a life cycle policy for the 

To achieve this, the ORB will have a modular structure service session object 

allowing the implementation of different profiles, depending 8 A melhod as clakned in daim ? characterized in that 

on application or service requirements. IJese profiles give 5 ^ fo object im lemcms a creation on demand life 

an abstraction of the resources provided by the underlying , c 4 , . . ,. t 

r\ c.u nnn a 1 n u f -i c Y cle policy for the service session object, 

operating system. One of the ORB modules will be a failure n * L j , - ^ • i • - L • j * t_ 

detector which is at the lower level of the ORB structure. tU 9 f A , meth ° k d aS d T m daim ? ' characte " zed m * at 

And a response Invocation delay beyond a certain threshold the 5**°? °^ct implements an activation on demand life 

is classified as failure. Thus, the client is able to trade off 10 c y cle P 01 "* for the session ob J ect ' 

reliability for timeliness, the shorter the threshold, the tighter 10 - A method ^ claimed in claim 1, characterized m that 

the bounds on delays. By replicating an object in a sufficient aU factions for controlling the execution of the service are 

number of times, the client is able to meet both timeliness implemented by a dedicated CORBA service server, 

and reliability requirements simultaneously. U- A method as claimed in claim 1, characterized in that 

Here, we have identified a requirement for a replication 35 the service session object has an interface definition which 

service with correctness, safety and liveness properties; and is Transactional Capabilities Application Part mapped over 

a failure detector module which is part of the ORB core. Interface Definition Language. 

Performance: 12. A method as claimed in claim 1, characterized in that 

Performance of IN are measured in number of calls per me service session object directly receives its own message 

second for service nodes and intelligent peripherals; and 2 o mvocat i° ns - 

number of transaction per second for signaling control point. 13- A method as claimed in claim 1, characterized in that 

These calls and transactions may involve multiple messages me service session object receives Information Networking 

exchanged between an SSP and the Intelligent Layer. Architecture messages as message invocations from the 

To obtain the actual performance of legacy IN systems, service switching exchange, 

real-time performance of the ORB is required for the use of 25 I 4 A method as claimed in claim 1, characterized in that 

distributed processing in IN systems as well as its distribu- tne service session object runs in its own thread, 

tion on a geographical scale (non centralized IN systems). 15. A method for provisioning execution of a service logic 

To achieve better performance for IN distributed systems, function within a service control facility of a telecommuni- 

the ORB call overhead should be reduced, and the perfor- cation system, wherein service requests that request execu- 

mance level that the ORB must achieve in terms of latency, 30 tion of tne service logic function are received by the service 

throughput, etc., should be defined and documented. control facility from at least one service switching exchange 

What is claimed is: of the telecommunication system, comprising the steps of: 

1. A method of providing a service for users of a tele- creating within the service control facility a respective 
communication network, wherein service calls requesting service session object for each of the service requests 
execution of the service for a respective one of the users are 35 received from the at least one service switching 
routed to one respective service switching exchange of the exchange, and 

telecommunication network, and wherein a corresponding handling the execution of the service logic function for 

service request is sent, by the respective service switching each of the service requests, wherein the service session 

exchange that has received one of the service calls, to a ob j ect ^ able to interacl and commurnC ate via an object 

respective service control facility, comprising the following 40 infrastructure with other objects in an object oriented 

sle P s: computing environment, and wherein the execution of 

creating within the service control facility a service ses- the service logic function is handled by the respective 

sion object for each of the service requests, and service session object, 

controlling the execution of the service for the respective 16. A service control facility for connecting to one or 

service call, wherein the service session object is able 45 several service switching exchanges of a telecommunication 

to interact and communicate via an object infrastructure network, where the service control facility contains means 

with other objects in an object oriented computing for receiving service requests, that request the execution of 

environment, and wherein the execution of the service a service for a user of the telecommunication network, from 

is controlled by the respective service session object. at least one of the service switching exchanges of the 

2. A method as claimed in claim 1, characterized in that 50 telecommunication network, characterized by containing 
the service switching exchange communicates with the means for creating for each such service request received 
service control facility according to the communication from the at least one service switching exchange a service 
protocols of the Intelligent Network Architecture. session object within the service control facility, means for 

3. A method as claimed in claim 1, characterized in that enabling each service session object to interact and com- 
the service session object interacts and communicates as a 55 municate via an object infrastructure with other objects in an 
CORBA object via a CORBA object infrastructure with object oriented computing environment, and means for 
other objects for controlling the execution of the service. executing under control of the respective service session 

4. A method as claimed in claim 1, characterized in that object a service logic function for the respective service 
the service control facility controls and carries out the request. 

execution of different services for users of the telecommu- 60 17. The service control facility according to claim 16, 

nication network. characterized by containing a variable number of processing 

5. A method as claimed in claim 1, characterized in that nodes for processing service session objects. 

the creation of each service session object is managed 18. A processing node for a service control facility con- 
through a factory object. nected to one or several service switching exchanges of a 

6. A method as claimed in claim 1, characterized in that 65 telecommunication network, where the processing node 
the creation of each service session object is managed by a contains means for receiving service requests, that request 
service dedicated factory object. the execution of a service for a user of the telecommunica- 
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tion network, from at least one of the service switching 
exchanges of the telecommunication network, characterized 
by containing means for creating for each such service 
request received from the at least one service switching 
exchange a service session object, means for enabling each 
service session object to interact and communicate via an 
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object infrastructure with other objects in an object oriented 
computing environment, and means for executing under 
control of the respective service session object a service 
logic function for the respective service request. 
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